An Agent-Based Model of the Spread of Devil Facial Tumor Disease in an Isolated Population of Tasmanian Devils

The advances in Intelligent Transportation Systems (ITS) call for a new generation of traffic simulation models that support connectivity and collaboration among simulated vehicles and traffic infrastructure. In this paper we introduce MATISSE, a complex, large scale agent-based framework for the modeling and simulation of ITS and discuss how Alloy, a modeling language based on set theory and first order logic, was used to specify, verify, and analyze MATISSE’s traffic models. DOI: 10.4018/jats.2012100103 International Journal of Agent Technologies and Systems, 4(4), 38-60, October-December 2012 39 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. proposed ITS components have already been implemented, the overall infrastructure is still in its conceptual phase. Given the critical role of interactions among ITS components and their independent decision making capabilities, it is essential to simulate traffic scenarios under nominal and extreme conditions before deploying the physical infrastructure on roads and highways. MATISSE (Multi-Agent based TraffIc Safety Simulation systEm) is an agent-based “tailor made” simulation framework designed to provide a platform for the execution of such scenarios. MATISSE provides means to analyze and evaluate different ITS configuration, collaboration, and control strategies. Before embarking on the full-scale development of this large-scale, distributed, multi-agent based simulation framework, the specification and validation of MATISSE’s properties proved to be necessary. Alloy is a modeling language based on set theory and first order logic that has been used in both industry and academia to validate a wide variety of systems (Coppit & Sullivan, 2000; Dolby, Vaziri, & Tip, 2007; Jackson & Vaziri, 2000). The language has a simple and concise syntax that comes with a powerful, integrated tool for compiling and analyzing models. The purpose of this paper is to present a formalization of the MATISSE model in Alloy, and discuss how the model’s core properties are verified using Alloy’s Analyzer. In particular, we discuss an approach to produce execution traces from the specification. These traces serve two purposes: they allow for a thorough analysis and evaluation of the traffic model; and demonstrate the suitability of MATISSE for the simulation of ITS scenarios. In the following section we give an overview of traffic simulation systems. In Section 3 we briefly present the proposed ITS and MATISSE’s high level architecture. In Section 4 and section 5 we discuss how Alloy has been used to specify, verify, and analyze MATISSE’s model. In Section 6 we present an evaluation of the approach. Finally, in Section 7 we give an overview of related works. 2. TRAFFIC SIMULATION There are two major approaches to simulate traffic scenarios. Macroscopic models (Babin, Florian, James-Lefebvre, & Spiess, 1982; Lieu, Santiago, & Kanaan, 1992) describe traffic as a physical flow of fluid and make use of mathematical equations relating macroscopic quantities (e.g., traffic density, flow rate and average velocity). These models assume rational driving behavior and fairly consistent traffic streams and thus are unfit to model real traffic operations. In contrast, microscopic models consider the characteristics of individual traffic elements (e.g., vehicles, traffic lights, traffic signals, driver behavior) and their interactions. Typical microscopic models are based on analytical techniques such as queuing analysis and shock-wave analysis (Helbing & Tilch, 1998). They assume traffic elements with predefined behavioral models. This is a limitation since realistic traffic simulation scenarios call for the modeling of unexpected behavior and unforeseen environmental conditions. The multi-agent paradigm alleviates this limitation by providing means to address non-deterministic behavior in non-deterministic, unpredictable environments. Over the last decade, a large number of agent-based traffic simulation systems have been proposed. Some focus on specific small scale traffic problems such as driver behavioral modeling, tactical driving, and intersection management (Dresner & Stone, 2008; Rossetti & Liu, 2005; Sukthankar, Hancock, & Thorpe, 1998) while others attempt to tackle complex large scale traffic scenarios (Balmer et al., 2009; Cetin, Nagel, Raney, & Voellmy, 2002; Galland, Gaud, Demange, & Koukam, 2009). In this section we restrict our discussion to those that best compare to MATISSE, namely MatSim (Balmer et al., 2009), and Transims (Cetin et al., 2002). MatSim (Balmer et al., 2009) is an agentbased framework for modeling transport demand. MatSim represents individual travelers as agents endowed with predefined plans. These agents follow a utility based strategy to 40 International Journal of Agent Technologies and Systems, 4(4), 38-60, October-December 2012 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. determine their optimal daily plan. Interactions among agents are implicitly encoded into the agent’s utility function. In its current version, traveler agents cannot directly interact with other agents. In addition, agents are not capable of perceiving their environment dynamically. They act upon global environmental knowledge seeded at initialization time. Similarly, Transims (Cetin et al., 2002) is a large-scale microscopic simulation system for transportation planning and congestion evaluation. In Transims travelers are modeled as agents which can walk, drive cars, or use buses. Traveler agents can decide which plan to select depending on their current state but they cannot dynamically perceive their environment. It is also unclear whether they can interact with other agents. Transims’ environment is static and fully observable, thus reducing its capabilities to model complex and realistic scenarios. Our work enhances the conventional urban traffic simulation by proposing a multi-agent based framework that simulates macroand micro-level traffic entities and their interactions within and across levels. The unique characteristics of MATISSE are: 1) the simulation environment is open, i.e., non-deterministic, dynamic, inaccessible and continuous (Russell & Norvig, 1995). The environment has mechanisms that allow the simulation of event propagation. 2) The agents are not given global environmental knowledge to act upon. They dynamically perceive their surroundings through various senses. 3) At run-time, the user can change the properties of the simulated agents (e.g, driver “awake” to driver “asleep”, disable agent sensors) and the environment (e.g., change the laws that govern the environment) without interrupting the simulation. To the best of our knowledge, no other existing framework offers this integrated set of features. A recent system called JaSim (Galland et al., 2009) was developed along the same premises as MATISSE. Even though it shares the same environment structure and similar agent perception mechanisms, it lacks the advanced simulation features of event propagation and dynamic property modification discussed above. 3. OVERVIEW OF ITS AND MATISSE In this section, we briefly present the main components of the proposed ITS and discuss MATISSE’s architecture. More detailed discussions on these topics can be found in (Boyraz et al., 2009a; Wenkstern et al., 2009a; Wenkstern, Steel, & Leask, 2009b). 3.1. Elements of a Novel ITS The proposed ITS aims at enforcing communication, interaction, and collaboration between various types of elements defined at various levels of abstraction. In the remainder of this paper we will use the word “micro-level” element to refer to an entity that has very limited knowledge of the state of the world. In contrast, a “macro-level” element refers to one that is aware of a larger portion of the world. The infrastructure is based upon two underlying concepts: • In order to manage a large environment efficiently, it is necessary to partition the space into smaller defined regions called traffic area; • Each traffic area is assigned a tower. A tower is required to: 1) autonomously manage environmental information about its traffic area; 2) be aware of the traffic elements (e.g., vehicles, traffic devices) located in its defined area; 3) be able to interact with local traffic elements to inform them about changes in their surroundings; 4) be able to communicate with other towers to inform them of external events. In order to manage traffic information efficiently, traffic towers are organized as a hierarchy (see Figure 1). This structure is particularly important for the case when towers need a higher level of knowledge to properly manage their traffic areas. For example, if congestion is caused by an accident in an area, and the micro-level information is insufficient for the tower to determine the best exit route International Journal of Agent Technologies and Systems, 4(4), 38-60, October-December 2012 41 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. for its local vehicles, it will communicate with a higher level traffic tower to obtain a broader image of the traffic. The micro-level entities are classified in two categories: • Mobile Context-Aware Intelligent (CAI) vehicles (Boyraz, Yang, Sathyanarayana, & Hansen, 2009b). These are vehicles equipped with devices that allow them to 1) monitor the driver’s behavior in order to prevent possible accidents; 2) communicate with other vehicles and traffic devices; and 3) interact with the traffic tower infrastructure to obtain traffic information and guidance in real time; • Stationary Context-Aware Intelligent (CAI) traffic devices. These include traffic lights, traffic collection devices, and relay units. They serve the purpose of improving safety and traffic flow on roads and highways by providing information about the physical traffic infrastructure and congestion condition. Traffic lights are equipped with adaptive systems that allow them to 1) interact with the traffic tower infrastructure to obtain traffic information in real time, 2) communicate with vehicles for intersection coordination, and 3) communicate with other traffic light controllers to improve traffic flow when necessary. Traffic collection devices are used on highways to collect information about traffic, and communicate the information to the traffic management system for further analysis (e.g., identification of a drunk driver on the highway). Relay units are used to pass on information between the various communicating entities when the physical distance is too great. 3.2. MATISSE Architecture MATISSE is a “tailor made” multi-agent based simulation platform designed to specify and execute simulation models for the abovementioned ITS. We define an agent as a software entity which (Mili, Steiner, & Oladimeji, 2006): 1) is driven by a set of tendencies in the form of individual objectives; 2) can communicate, collaborate, coordinate and negotiate with other agents; 3) possesses resources of its own; 4) executes in an environment that is partially perceived; 5) possesses skills and can offer services. A virtual agent is an application specific agent that represents a real world concept (e.g., vehicle, traffic device). Figure 1. ITS super-infrastructure 42 International Journal of Agent Technologies and Systems, 4(4), 38-60, October-December 2012 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. As shown in Figure 2, a virtual agent consists of four main modules (Mili et al., 2006). The Interaction Module handles an agent’s interaction with external entities and separates environment interaction from agent interaction. The Environment Perception Module contains various perception modules emulating the agent’s senses and is responsible for perceiving information about an agent’s environment. The Agent Communication Module provides an interface for agent-to-agent communication. The Knowledge Module is partitioned into External Knowledge Module (EKM) and Internal Knowledge Module (IKM). The EKM serves as the portion of the agent’s memory dedicated to maintaining knowledge about entities external to the agent, such as acquaintances and objects situated in the environment. The IKM serves as the portion of the agent’s memory dedicated for keeping information that the agent knows about itself, including its current state, physical constraints, and social limitations. The Task Module manages the specification of the atomic tasks that the agent can perform and the Planning and Control Module serves as the brain of the agent; it uses information provided by the other modules to plan, initiate tasks, make decisions, and achieve the agent’s goals. MATISSE defines virtual agents for each microand macro-level element used in the ITS. Vehicle agents simulate the behavior of human drivers; have individual goals such as arriving at some destination in a reasonably short time; influence other agents such as turning signals and changing lanes; and are governed by environmental norms and constraints such as speed limits and traffic signals. Traffic light and traffic collection agents are aware of and influence nearby vehicles; are able to perceive and adapt to changing conditions; and work collaboratively to achieve certain objectives. Finally, traffic tower agents autonomously manage and control their traffic area, including the vehicles and traffic devices they enclose. In addition to these virtual agents, and for software design purposes, it is necessary to introduce two design related concepts: a cell is a repository that encompasses all informaFigure 2. Virtual agent architecture International Journal of Agent Technologies and Systems, 4(4), 38-60, October-December 2012 43 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. tion related to a traffic area. A cell controller is a special purpose agent whose main role is to consistently provide virtual agents located within its cell with a correct perception of their surroundings. This is a complex and critical role in any realistic simulation. More information on this topic can be found in (Mili & Steiner, 2007). It is important to note that a cell controller does not correspond to a real world concept. 3.2.1. High Level Architecture As shown in Figure 3, MATISSE’s high level architecture includes three main components: the Agent-Environment System (AES) creates simulation instances; the Data Management System (DMS) stores and processes information collected from the AES; and the Visualization Framework receives information from the DMS and creates 2D or 3D images of the simulation. 3.2.2. MATISSE’s Virtual Agent Platforms The four types of agents identified by MATISSE are naturally managed by four distinct agent platforms within the Agent-Environment System component. The Virtual Vehicle Platform manages mobile agents that represent vehicles. Vehicle-agents are created by the Vehicle-Agent Management Component, and vehicle-agents communicate with each other through the Vehicle-Vehicle Message Transport Service. The Virtual Traffic Device Platform manages stationary agents that represent traffic lights, relays and information collection devices. The Traffic-Device-Agent Management Component creates and manages traffic-device-agents within the simulation while Device-Device Message Transport Service handles communication between these stationary traffic-agents. The Figure 3. Matisse high level architecture 44 International Journal of Agent Technologies and Systems, 4(4), 38-60, October-December 2012 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Virtual Tower Platform creates and manages the hierarchical infrastructure of traffic-toweragents. Finally the Simulated Environment Platform creates and manages cell controllers. The Environment Agent Management Component creates cell controllers, assigns them to a cell, and maintains the cell controller hierarchy for the simulation. 4. SPECIFYING MATISSE IN ALLOY Due to the scale and complexity of the simulation architecture, from a software engineering perspective, we found it necessary to formally specify and validate various simulation properties before starting the implementation of MATISSE. In this section we briefly introduce the Alloy language (Jackson, 2002) and present a specification of the simulation properties of MATISSE in Alloy. 4.1. Overview of Alloy In the past two decades, several formalisms have been proposed for multi-agent systems (e.g., temporal logic, multi-modal logic). These formalisms are generally abstract and not related to concrete computational models (D’Inverno et al., 1997). Other approaches have used traditional formal languages such as Z and CSP (Brazier, Dunin-Keplicz, Jennings, Treur, & Lesser, 1995; Luck & D’Inverno, 2001). While providing an accessible notation, these formalisms lack the diagrammatic representation and tool support necessary to effectively analyze models. Alloy is a specification language based on set theory and first-order relational logic (Jackson, 2002). The language has a simple and concise syntax that can represent complex structural properties and behavior. It comes with an Analyzer, a powerful, integrated tool for compiling and analyzing models. The Analyzer supports two types of automatic analysis: 1) the search for an instance that satisfies all the constraints and relations specified in a model; 2) the identification of a counterexample that violates the assertions specified in a model. Both analysis are performed within a user defined scope that bounds the cardinality of entity sets in instances of the model. Outputs can be graphically depicted using the visualizer and evaluated using the command-line evaluator. Alloy has been used in both industry and academia (Coppit & Sullivan, 2000; Dolby et al., 2007; Jackson & Vaziri, 2000). Jackson and Vaziri (2000) have proposed an approach to verify Java methods in Alloy. At IBM, a subset of Alloy has been used to develop a technique for efficient checking of data structure invariants (Dolby et al., 2007). Alloy was also used in (Coppit, Yang, Khurshid, Le, & Sullivan, 2005) to test and find bugs in Galileo, a dynamic fault tree analysis tool used at NASA (Coppit & Sullivan, 2000). 4.2. MATISSE Metamodel For the purpose of specifying MATISSE in Alloy, we introduce a set of related concepts based on the discussion presented in Section 3. Figure 4 depicts the traffic domain concepts of the simulation. It describes the different types of virtual agents, their environment and organizational relationships. In this model, the Virtual Environment consists of Traffic Areas and represents the environment where Virtual Agents are situated in. A Tower provides guidance to virtual agents within its managed traffic area while being able to collaborate with other towers. Figure 5 depicts Cells and Cell Controllers as previously discussed in Section 3. In addition, it defines Communication Medium as an abstraction of the communication mechanisms for vehicle to vehicle and vehicle to traffic infrastructure interactions. The relation vicinity represents a virtual agent’s range of communication. 4.3. Specification of MATISSE Static Properties The static properties of a model describe entities and their relationships. In Alloy, these are specified through the signature declaration. International Journal of Agent Technologies and Systems, 4(4), 38-60, October-December 2012 45 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Figure 4. Traffic metamodel Figure 5. Simulation metamodel 46 International Journal of Agent Technologies and Systems, 4(4), 38-60, October-December 2012 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. For example, in the following specification excerpt, module TrafficSimulation Entity specifies vehicle-agents, traffic-light-agents, and tower-agents. It also specifies VirtualEnvironment, TrafficArea, Cell, CellController, and CommunicationMedium. The one keyword constraints the model to one virtual environment. Simulation events (both external and internal) are specified by Event and emergency alerts are specified by Alert. 1 module TrafficSimulationEntity 2 abstract sig VirtualAgent{} 3 sig Vehicle extends VirtualAgent{} 4 sig TrafficLight extends VirtualAgent{} 5 sig Tower extends VirtualAgent{} 6 one sig VirtualEnvironment{} 7 sig TrafficArea{} 8 sig Cell{} 9 sig CellController{} 10 sig CommunicationMedium{} 11 sig Event{} 12 sig Alert extends Event{} The following specification fragment shows a partial specification of MATISSE’s model. module TrafficSimulation makes use of the elements defined in module TrafficSimulationEntity to specify the relations and constrains of the model. An example of a relation, in sig Simulation, is guide that corresponds to the relationship between tower-agents and virtual-agents (e.g., vehicle-agents, traffic-lightagents). The aggregation of module TrafficSimulationEntity and TrafficSimulation makes up the complete MATISSE simulation model. 1 module TrafficSimulation 2 open TrafficSimulationEntity 3 sig Simulation{ 4 dividedIntoArea: VirtualEnvironment one 5 → TrafficArea, 6 guide: Tower lone → VirtualAgent, 7 manage: Tower one → one TrafficArea, 8 contain: TrafficArea one → VirtualAgent, 9 towerCollaborate: Tower → Tower, 10 ccCollaborate: CellController → CellController, 11 dividedIntoCell: VirtualEnvironment one → Cell, 12 ccManage: CellController one → one Cell, 13 cellContain: Cell lone → VirtualAgent, 14 influence: VirtualAgent → Event → CellController, 15 perception: CellController → VirtualAgent, 16 knows: VirtualAgent → Event, 17 vicinity: CommunicationMedium → VirtualAgent 18 → VirtualAgent, 19 transmitted: VirtualAgent → Event 20 → CommunicationMedium, 21 relayed: CommunicationMedium → Event →VirtualAgent, 22 sent: VirtualAgent → Event → Tower, 23 notified: Tower → Event → VirtualAgent, 24 propagated: Tower → Event → Tower 25 }{ 26 ... 27 contain (TrafficArea \ 28 → (VirtualAgent Tower)) = ~manage 29 all va: (VirtualAgent Tower) | one t: Tower | 30 t → va in guide 31 no t: Tower | t → t in guide 32 all t, t’: Tower | 33 not ((t → t’ in guide) and (t’→ t in guide)) 34 towerCollaborate = ~towerCollaborate 35 ... 36 } Alloy enables the precise specification of static properties such as “each tower-agent manages a virtual traffic area”. Using relation multiplicities, manage: Tower one → one TrafficArea specifies a one-to-one relation between tower and traffic area elements. Further, the constraint contain − (TrafficArea → (VirtualAgent − Tower)) = ~manage ensures that each tower-agent is assigned to a unique traffic area, and that each area is uniquely associated to its tower-agent. International Journal of Agent Technologies and Systems, 4(4), 38-60, October-December 2012 47 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 4.4. Specification of MATISSE Dynamic Properties In Alloy, operations are specified through predicates, which relate valid instances of Simulation through a change in its composition. For instance, pred sendMessage makes use of the function fun getTransmittedMessage to add the relation between a virtual agent and the communication medium to s in order to produce s’, in which s and s’ denote the before and after states of Simulation. 1 pred sendMessage[va: VirtualAgent, s, s’: Simulation]{ 2 s’.transmitted = s.transmitted 3 + getTransmittedMessage[va, s] 4 } 5 6 fun getTransmittedMessage[va: VirtualAgent, 7 s:Simulation]: VirtualAgent → Event 8 → CommunicationMedium { 9 (s.knows → CommunicationMedium) 10 ((VirtualAgent va) → Event → CommunicationMedium) 11 } Thus far, the presented specification produces arbitrary, unrelated instances of the MATISSE simulation model. In order to model the system behavior, it is necessary to define relations between instances and make use of execution traces. To produce execution traces, we specify a linear ordering over Simulation elements (see Figure 6). This is achieved by importing the library module util/ordering. This module includes functions first, next, and last. As depicted by Figure 6 (b), first returns the first element S1, s1.next returns S2 and s2.next returns S3, and last returns the last element S3. The following fragments of MATISSE’s specification illustrate the new constraints added to the model to enable execution traces. The pred init defines the initial conditions (i.e., the initial composition) and pred inv defines invariants (i.e., properties that never change during an execution trace) of Simulation. Any adjacent Simulation in the ordering is related by fact traces. For instance, the following trace fragment specifies short-range vehicle-to-vehicle and vehicle-to-infrastructure interactions. If a vehicle has transmitted a message in s, then the message is relayed to its recipients in s’ through operation relayMessage (lines 18 to 23). Similarly, if a message has been relayed in s, then the message is stored in each recipient’s knowledge base in s’ through operation receiveMessage (lines 25 to 30). 1 module TrafficSimulation 2 open util/ordering[Simulation] as t 3 4 pred init[s:Simulation]{ ... } 5 pred inv[s, s’:Simulation]{ 6 s’.dividedIntoArea = s.dividedIntoArea 7 s’.guide = s.guide 8 ... 9 } 10 fact traces { 11 init[first] 12 13 all s:Simulation last | let s’ = s.next { 14 inv[s,s’] 15 ... Figure 6. (a) Unrelated instances of the model and (b) Execution trace of the model 48 International Journal of Agent Technologies and Systems, 4(4), 38-60, October-December 2012 Copyright © 2012, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 16 // vehicle-to-vehicle interactions 17 // and vehicle-to-traffic-devices interactions 18 let va=((s.transmitted).Communication-